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A COMMUNICATION SYSTEM 



Field of invention 

5 The present invention relates to a communication system, in 
particular to the provision a presence service in a 
communication system. 



10 



Background to the Invention 

A diverse range of communication systems are in use today 
enabling communication between two or more entities, such as 
user equipment and/or other nodes associated with the system. 

15 Communication systems proving wireless communication for user 
terminals or other nodes are known. An example of a wireless 
system is a public land mobile network (PLMN) . A PLMN is 
typically a cellular network wherein a base transceiver 
station (BTS) or similar access entity serves user equipment 
20 (UE) such as mobile stations (MS) via a wireless interface. 
The operation of the apparatus required for the communication 
is usually controlled by one or more control entities, which 
themselves may be interconnected. One or more gateway nodes 
provide for connecting the PLMN to other networks. Examples of 
25 other such networks are another cellular network, a public 
switched telephone network (PSTN) and packet switched data 
networks such as an IP (Internet Protocol) based network. The 
communication between the user equipment and the other 
elements of the communication system, are based on an 
30 appropriate communications protocol, which defines the "rules" 
under which communication is handled in the system. 
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In the current third generation (3G) wireless system, there 
are defined various servers for the handling of different 
communication services for mobile users. These include servers 
that provide call state control functions, known as CSCFs . 
Control functions may also be provided by entities such as a 
home subscriber server (HSS) and applications by various 
application servers. The HSS is typically for permanently 
storing the user's profile and used during authentication, for 
example, in the Release 5 architecture for 3G, as specified by 
the 3 rd Generation Partnership Project (3GPP) , these entities 
can be found located in the IP Multimedia Subsystem (IMS) . 

The IMS network may sit at the hub of the 3G architecture, 
supporting an IP based network that handles both traditional 
voice telephony and multimedia services. The 3 GPP has chosen 
Session Initiation Protocol (SIP) as a core session signalling 
protocol for 3G networks. SIP has been developed by. the 
Internet Engineering task Force (IETF) . Those interested can 
find the 3 GPP specification 24.229 describing the IMS 
network's basic operation from an SIP perspective titled "IP 
Multimedia Call Control Protocol based on SIP and SDP" at 
httpt //www. 3gpp.org/ftp/Specs/Latest-drafts/24229-2Ql. zi p. SIP 
is a request/response style protocol,' in the sense that for 
every message sent from a source, there is an associated 
response from the destination confirming receipt of the sent 
message. (The acknowledgement ACK message is a special case to 
which no response is sent) 

For example, in a 3G network, when a user first switches on 
his mobile terminal, he must register his user ID or address 
with the network before allowing the terminal to fully 
connect. This is done by sending an SIP * REGISTER' message 
from the terminal to the IMS, which includes details of the 
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users address- The IMS receives and processes this information 
using a serving call state control function (S-CSCF) , which in 
this context is referred to as the "registrar" " . The REGISTER 
message is only used to provide mapping between a user's alias 
and contact address e.g. mapping alias 

sip:mikko. lonnfors@sonera.com to a terminal's IP address. The 
IMS acknowledges the registration by sending a suitable 
acknowledge message (e.g. 200 OK message) in accordance with 
SIP. Subsequent registrations also take place (re- 'REGISTER' ) 
whenever the preceding registration has expired or is 
expiring, or when there is a change in the status of the user. 
When a user wishes to set up a session with another user, such 
as a voice call or messaging session (there is another way of 
sending messages i.e. with a SIP MESSAGE and in this case 
session establishment is not required) , the session 
negotiation will also be performed under SIP. 

Application servers (AS) may supply services via the IMS such 
as instant messaging, presence, local traffic reports, and 
conferencing facilities. An AS may reside within the. IMS 
network, or outside of it. Typically the AS is external when 
the service supported is provided by a third party- 
One specific example of status information is presence 
information. Users or application servers subscribing to a 
presence service can determine the ability and availability of 
another user e.g. to accept a call (depending on the equipment 
and service provider) among other presence 

features/attributes. However, in systems supporting SIP, 
presence can assume a variety of indicators such as x in the 
office and available for all calls', x at home and available 
for private calls only', and x busy in call' (or at least 
appear that way) . Thus presence information allows a user to 
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ascertain the availability of another user before attempting 
to make a call. The presence service can provide more than 
just information such as available/not available. It can 
contain visual, animated or sound elements and can describe 
various issues for example related to a game session. 

This presence service which is being standardised in OMA 8 
(open mobile alliance (www.openmobilealliance.org)), 3GPP and 
IETF is gaining more and more attention. It is expected that 
the number of presence aware applications will increase in 
future. As the number of applications increase it also 
increases the amount of presence information. From the 
receiving terminal perspective the increase of information 
poses a challenge as to how to treat the presence information 
i.e. which parts of the presence information are relevant to 
which application (s) . A terminal may run one or more 
applications. For example, the terminal can run a dynamic 
phone book application and a games application. 

In the current IETF and 3 GPP models, a tuple structure is 
used. The tuple contains a 'random' TUPLE ID which does not 
have any semantics i.e. it cannot be used describe the purpose 
of the tuple. In each tuple there can be several attributes. 
Moreover, different tuples may have attributes that have same 
name but are intended to be used/ interpreted differently 
depending on the sending/receiving application. For example 
the presence information can contain two tuples (one for games 
and one for a dynamic phonebook (DPB) ) and each of these 
tuples may contain a status field. The dynamic phone book may 
have been designed to understand status values: available, 
discreet, not available whereas the game may be designed to 
understand status values: shooting, dead, paused, lost. As can 
be seen from this example, the status fields have to be 
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delivered to the correct application if they are to have the 
correct meaning. This is a problem when a terminal has two or 
more applications. This is also a problem even if the 
receiving terminal has only one application and sending 
terminal or presentity has multiple ones. If the data as 
provided in the example is delivered to the terminal having 
only e.g. DPB, the receiving terminal needs to be able to 
determine which tuple was intended for the DPB application. * r 

Currently, there - is no mechanism to pass the information to 
the correct applications other than for each application to 
check each tuple and see if _ the status values have any meaning 
for the application. In other words a trial and error approach 
is adopted. However, this creates uncertainty as to 
correctness of the information. This is because in some cases 
even if the value may be the same for an attribute, it may be 
interpreted incorrectly by the wrong application. An example 
of this is as follows: a sending terminal has a DPB and a IM 
(instant messaging) application. It sets status values: DPB = 
Closed, IM = Open. In this example both applications would 
use only status values open and closed. Now if the receiving 
terminal only has an IM application and it receives both the 
DPB and IM statuses. If the receiving terminal tries the first 
status .value of DPB it understands it and presents that to the 
user via the IM application saying that IM application in the 
presentity' s terminal was closed even though it was open. 

It has been proposed that where a user wants to obtain 
presence information about one other user that the user is 
able to include filters to reduce the data from the presence 
server, that is the presence information. These filters are 
able to reduce the data from the presence server to include 
only parts that are of interest for the user. 
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The approach where both the tuple identities are used as a 
filtering criteria by watchers (users requesting presence 
information) and also the authorization is based on tuple 
5 identities has many disadvantages. If for example a user being 
watched has 4 tuples (Tl, T2 , T3 and T4) and one watcher is 
only interested in tuples T2 and T3, the watcher sets filters 
to allow only tuples T2 and T3 to be notified to him. The 
watched user may then decide for some reason to start showing 

10 different values, to the particular watcher concerning all 
tuples. Therefore the watched user creates new tuples T5 , T6, 
T7 and T8 and creates a new access list, which allows the 
watcher to see tuples T5-T8, but not the tuples T1-T4 . But 
the watcher has set the filtering based on the tuple identity, 

15 which means that no tuples are provided to him. This is 
disadvantageous . 

Another disadvantage of using the tuple identities in 
filtering is that normally the presentity does not want 
20 watchers to know that a particular watcher is not allowed to 
get as detailed information as another watcher, or that the 
information given to different watcher groups is slightly or 
totally different from the information given to other 
watchers . 

25 

It is disadvantageous if the filtering settings change every 
time a watcher's authorization information is changed because 
of different detail level of information is provided to the 
watcher. This would be the case if the filtering is based on 
30 the unique tuple identities. 

Summary of the invention 
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Embodiments of the present invention aim to overcome one or 
several of the above problems. 

According to one aspect of the present invention, there is 
provided a communication system comprising a lest one user 
with which presence information is associated, said presence 
information comprising a plurality of parts, at least one of 
said parts comprising information identifying the application 
for which said at least one part is intended. 

According to a second aspect of the present invention, there 
is provided a communication method comprising the steps of 
providing presence information for an associated user, said 
presence information comprising a plurality of parts, at least 
one of said parts comprising information identifying an 
application for which said at least one part is intended; and 
at least one entity obtaining at least one of said parts, said 
at least one entity having at least one entity application, 
the at least one entity obtaining the parts comprising 
information identifying said at least one entity application. 

According to a third aspect of the present invention, there is 
provided a user in a communications system, said user having 
associated presence information, said presence information 
comprising a plurality of parts, said user being arranged to 
provide at least one of said parts with information 
identifying an application for which said at least one part is 
intended . 

According to a fourth aspect in the present invention, there 
is provided an entity in a communications system, said entity 
comprising at least one application obtaining means for 
obtaining at least one part of presence information associated 



WO 2004/034718 




PCT/IB2002/004381 



with an user, the at least one part comprising inf ormation 
identifying an application, the obtaining means being arranged 
to obtain the at least part comprising information identifying 
said at least one application. 

5 

The quite static filtering settings possible with embodiments 
of the invention are useful especially when the filters are 
stored in a certain server (e.g. in the presence list case) 'or 
the like beforehand. 

10 

Embodiments of the invention may permit the hiding of the fact 
from watchers that there is a different level of information 
(or totally different information) to available to different 
watchers . 

15 

Embodiments of the invention may allow changes in 
authorization without affecting e.g. filtering settings or 
some other functionality which can be separated from the 
authorisation by giving more semantics to presence information 
20 elements 

Embodiments of the invention may give the " watcher the 
possibility to request semantically understandable information 
instead of basing the request on "non-meaningful" identity 
25 information. 

Brief Description of Drawings 

For a better understanding of the present invention and as to 
30 how the same may be carried into effect, reference will now be 
made by way of example only to the accompanying drawings, in 
which: 
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Figure 1 illustrates a communication system wherein the 
present invention can be applied; 

Figure 2 illustrates schematically an embodiment of the 
invention; 

5 Figure 3 illustrates the embodiment of Figure 2 in more 

detail; 

Figure 4 illustrates the IMS part of the system of Figure 
1 in more detail; 

Figure 5 illustrates schematically an embodiment of the 

10 invention. 

Detailed description of embodiments 

Reference will now first be made to the Figure 1, which 
15 illustrates a typical 3 rd Generation (3G) Wireless 
telecommunications system operating under the Universal Mobile 
Telecommunications System (UMTS) . At the hub of this system is 
the IP Multimedia Subsystem (IMS) 100 network, which routes 
calls and all kinds of sessions between two or more users (or 
20 between user and a network element e.g. application server) of 
the network and provides other network functions. Examples of 
users are mobile terminal 111, laptop 112, personal desktop 
assistant (PDA) 113, Public Switched Telephone Network (PSTN) 
telephone 131, computer terminal 123, and application server 
25 121, and application server 122. The IMS uses an IP based 
network to handle these calls, which may include both voice 
calls and multimedia calls. 

The IMS network effectively acts as a gateway in a 3G system 
30 between the users 111, 112, 113, and other networks such as a 
PSTN 130 and external IP based network 120. Signalling between 
the mobile terminal and other users of the IMS network, and 
within the IMS network, is done under the Session Initiation 
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Protocol (SIP) . All references to messages that follow are SIP 
messages unless otherwise stated, and will be shown in 
capitals. It should be appreciated that although the preferred 
embodiments of the present invention have been described in 
the context of SIP, other embodiments of the invention can be 
implemented in non SIP environments. 

Reference will now be made to Figures 2 and 3 which show 
schematically an embodiment of the present invention. Figure 2 
shows a transmitting terminal 10 and a receiving terminal 12. 
The transmitting terminal 10 is arranged to provide presence 
information to the receiving terminal 12. A presence server 14 
is provided. The presence server 14 and the transmitting 
terminal are sometimes referred to as a present ity. The 
presence server 14 provides the receiving terminal 12 with the 
required presence information. The presence server 14 will 
receive the presence information from the transmitting 
terminal. It should be appreciated that the connection between 
the transmitting terminal 10 and the presence server 14 as 
well as the connection between the presence server 14 and the 
receiving terminal will be via network elements or entities 
not shown. 

in embodiments of the present invention, a transmitting 
terminal 10 (which can be any of the users as discussed above 
and can be referred to as a watched (or presentity) user) 
shall mark presence tuples so that receiving terminal 12 
(which can be any of the users discussed above and can be 
referred to as a watcher) and possibly the presence server 14 
can identify different parts of the presence information and 
pass them to the correct application. In particular, in 
embodiments of the present invention, a semantically 
meaningful application identity information field is provided 
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in each tuple or at least some tuples. This field is referred 
to as the application ID field. The information may be the 
identity itself or information relating to the identity. The 
transmitting application inserts an application specific 
5 identifier into that application identity information field 
which can be recognised at the receiving end. The receiving 
terminal passes the tuples to the applications in that 
terminal identified in the application ID field. 

This will be discussed in more detail with reference to Figure 
3. In step 1, the applications 16a, 16b and 16c residing in 
the transmitting terminal register their application 
identities with a presence engine 18 in the terminal. After 
this step applications can start publishing information, that 
is sending information to the presence server (and from there 
to the receiving terminal if the watcher has made a presence 
subscription) . In the example shown in Figure 3, the terminal 
is shown as having three applications. This is by way of 
example only and a terminal or other user can have more or 
less than three applications. . - 

In step 2, each application 16 publishes presence information 
in form that contains one or more tuples and the presence 
engine 'attaches the application ID to each tuple. After that 
25 the presence engine 18 forwards the information to the 
presence server 14 . In alternative embodiments the 

application can do the attachment of the application ID. 

In step 3, the presence engine 2 0 of the receiving terminal 12 
30 gets a NOTIFY message from the presence server 14 of new 
presence information. According to the application ID (carried 
in each tuple) the tuples are routed to the corresponding 
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applications 22 of the receiving terminal by the presence 
engine. Alternatively, each application can receive all of the 
tuples but will ignore any tuple which has the wrong 
application identity. 

5 

Thus every application would have it own application ID. For 
example gamel, game2, SMS, IM-1, IM-2, e-MAIL. If two 
terminals (1 and 2) have the same application, e.g. IM-1, the 
application ID is the same for that application. However, if 

10 terminal 3 has an application identified by IM-2 (made for 
example by another vendor) the application will have a 
different application ID than IM-1 application in terminals 1 
and 2 . In such cases the provided attributes may be used by 
the different application but care should be taken because it 

15 might be possible that the attributes or their values are not 
interpreted correctly. An example of this is where there are 
two different clients for IM. The basic functionality may be 
the same and thus the status attribute would be valid no 
matter which application interprets that but the remaining 

20 attributes may or may not be relevant at all . 

As the tuples contain the application identif icat-ion, it is 
possible to provide efficient (application specific) filtering 
capabilities and also to find the right application for which 
25 the tuples are intended. 

Tuples have general structure as presented in draf t-impp-cpim- 
pidf -05 . txt (link: http : //www. ietf . org/internet -draf ts/draf t- 
ietf-impp-cpim-pidf-05.txt]. Applications can then extend the 
30 "include additional inf ormation" options by defining new XML 
namespaces. XML is Extensible Markup Language (World Wide Web- 
a markup language based on SGML, and designed to remove the 
limitation imposed by HTML. Allows a page to contain a 
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definition and execution plan for the elements, and well as 
their content) . 

Who or what defines the different tuples to be used with 
different applications can vary. This may be dependent on the 
type of the application. Some or all tuples may be defined to 
have a standard format (standard attributes may be defined in 
for example the 3GPP standard) . Alternatively or in addition, 
it is possible for application developers to define tuples of 
their own. 

In general, there are no limits to the number of tuples or 
attributes within the tuples one presentity can have. 

The entity that will put the application ID into each tuple 
can be the presence engine or the application publishing that 
information. The uniqueness of the application ID may in some 
embodiments of the present invention require its registration. 
This may be the case with the uniqueness of the application ID 
is within other applications as well as other collections of 
information which need a semantic meaning. 

The application ID may be used in multivalue support and 
filtering. For example the application id can be used for 
hiding different "accuracy" levels of information. In that 
case the application id is not unique To clarify, the 
application information is unique in the sense that different 
applications should not use the same application ID but the 
same application ID can be present a multiple number of times 
in a presence server in the context of different tuples, the 
tuple- id is unique but there is the same application id in 
e.g. two or three tuples in a presentity' s presence 
information. The application id can then be used in the 
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filtering. In other words, the watcher (receiving terminal) 
may set a filter so that he does not receive all the available 
presence information from the watched user (presentity) . This 
filter may be set so that the watcher only receives presence 
information for certain applications, the filter filters out 
certain presence information or a combination of the two. 

For example, the following tuples are provided to the watcher 
(if provided by the presentity to the presence server) if a 
filtering is selected such that all tuples relating to "user 
provided location" are to be provided: 

Pre s entity =ABC 

TUPLE 1 

tuple-id: xyz3226 
application id = "user provided location" 
user provided location = TAMPERE 

TUPLE 2 

tuple-id: xyb3293 

application id = "user provided location" 
user provided location = HOME 

TUPLE 3 

tuple -id: xya3288 

application id = "user provided location" 
user provided location = x-coord, y-coord 

Reference is made to Figure 5 in which a first presentity 30 
provides tuples 1, 2, 3, 4 and 5 . Each tuple contains an 
application ID so tuples 1 and 2 have application ID «A" , 
tuples 3 and 4 have application ID "B" and tuple 5 has 
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application "C" . A watcher 32 only want tuples with 
application "A" . A filter 34 thus filters the tuples and 
provides the user 32 with tuples 1 and 2. It should be 
appreciated that in practice the filter may be part of the 
presentity, part of a separate entity such as a server or part 
of the watcher 32. The application ID is thus used to filter 
the tuples. 

The tuples may be intended for different users. Thus tuples 1, 
3 and 5 may be intended for one watcher and tuples 2 and 5 for 
a different watcher. Thus the watcher may only be able to 
"see" tuples 1, 3 and 5. Accordingly if the watcher wants only 
the tuples for application "A", the watcher would be provided 
with tuple 1. The filter 34 provides this additional 
filtering. In some embodiments of the invention a separate 
filter is provided or a directing means is provided for 
ensuring that a watcher only gets the tuples intended for it. 

It is also possible that different watcher groups have 
different presence information available to the respective 
groups . 

Embodiments of the present invention permit applications to 
easily . recognize from presence information what information 
that particular application can interpret and understand. 

It should be appreciated that in embodiments of the present 
invention, the application identity may be used by the 
presence server when it performs the filtering operation. In 
some embodiments of the invention, an operator specific 
application can be provided in the presence server which would 
also utilise the application IDs. The presence server could 
for example modify some attribute values inside a tuple it 
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understands and to which user has granted access rights to the 
presence server. 

Embodiments of the present invention can be used to filter. 
5 For example a watcher can request only part of the presence 
information which relates to one or more specific 
applications. The filtering can be done by the presentity 
being watched - either by the user or the presence server,^* by 
the watcher or by any other enity. The filter information can 

10 be prestored so that whenever presence information is provided 
by a specific presentity to a specific watcher, it will be 
filtered in accordance with the required applications. The 
filtering can define the applications required, the 
applications not required or by a combination of these 

15 techniques. 

As mentioned above a watcher is typically a user as discussed 
above. A u presentity" can be regarded as being a user and a 
presence server associated with that user. The presence server 
20 stores presence information for the users which are associated 
with that presence server. It should be appreciated that in 
practice, more than one user would be associated" with each 
server. The presence server may be located in an end device 
(in terminal) . 

25 

Presence information as currently defined in 3GPP can include 
the following information: (information but is not restricted 
to these and the requirements from stage 1 (requirements 
group) working on the standards is to develop a concept that 
30 enable presence to be extended. 

Subscriber status; Network status; communication means; 
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Contact address, Subscriber provided location; Network 
provided location; text; priority. 

Presence can also include other information like mood, 
5 favourite colour and etc . . 

It should be appreciated that embodiments of the invention are 
not restricted to the attribute called application identity 
information but can be applied to any attribute providing a 
10 similar type of operational possibility. 

Embodiments of the present invention are not limited to the 
use of tuples. Not all systems use tuples for structuring 
presence document, for example wireless village presence 
15 handles presence information at an attribute level and in such 
case the application ID is linked to each separate attribute. - 

Figure 4 shows a schematic of the IMS network 100. The IMS 
includes various elements including several Call State Control 
20 Functions (CSCF) . A CSCF is equivalent to a SIP server in the 
IETF architecture. 

The Interrogating CSCF (I-CSCF) 201 is the basic IMS node used 
for terminating calls in the IMS network, functioning at the 

25 edge of the network. Here, it is shown communicating with the 
external nodes of a mobile terminal 101, a PDA 113, and an 
application server (AS) 121. It should be appreciated that the 
connections between the mobile terminal, the PDA and the 
application server to the I-CSCF may not be direct, but via a 

30 suitable intermediate network such as the mobile core network 
110 for the mobile terminal, and the Internet 12 0 for the 
application server, as shown in Figure 1. 
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The HSS 202 is a centralised user database that interfaces 
with both the I-CSCF and the S-CSCF204, storing information on 
all users of the IMS . The I-CSCF uses the HSS to perform 
functions such as authorising of new users and retrieving 
routing information on the S-CSCF for forwarding messages from 
external elements to the S-CSCF. 

The S-CSCF is the IMS node responsible for invoking services 
related to IMS users. In this example, the S-CSCF also 
performs registrar functionality for IMS users, processing 
us£r registrations, The presence server functionality is 
implemented as application server. 

It should be appreciated that the description of Figure 4 is 
only a schematic representation and in practice additional 
elements such as for example a proxy-CSCF (P-CSCF) something 
missing from the sentence. It should also be appreciated .that 
embodiments of the invention may be used in systems other than 
those shown in Figure 4 . 

A presence package may be used for subscribing to the presence 
information of any user. The semantics of the presence package 
means that any user can send a subscription message for 
presence information to the presence server, but if there is 
no such presence package defined, the presence server would 
not be able to recognise to what event the user was trying to 
subscribe to. Therefore, the presence package needs to be 
defined at the presence server, which can then receive and 
recognise that the subscription message for the associated 
event for changes in presence information. The presence server 
creates a state linked to the presence information, and when 
any change in the presence information occurs, it will trigger 
a response or notification. 
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It should be appreciated that although embodiments of the 
present invention have been described in the context of 3G 
using SIP, other suitable systems and interface protocols 
5 could be used. In particular, embodiments of the present 
invention may be used in application in accordance with IETF 
specifications . 

It should also noted herein that while the above describes 
10 exemplifying embodiments of the invention, there are several 
variations and modifications which may be made to the 
disclosed solution without departing from the scope of the 
present invention as defined in the appended claims. 
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Claims : 



1. A communication system comprising: 

a least one user with which presence information is 
associated, said presence information comprising a plurality 
of parts, at least one of said parts comprising information 
identifying an application for which said at least one part is 
intended; and 

at least one entity to which presence information 
associated with said at least one user is provided, said at 
least one entity having at least one entity application, said 
at least one entity being arranged to use said information to 
obtain the at least one part intended for said at least one 
entity application. 

2. A system as claimed in claim 1, wherein said at least one 
entity comprises means for receiving said at least one part of 
said information. 

3. A system as claimed in claim 2, wherein said entity 
comprises means for directing said at least one part of said 
information to the identified entity application. 

4. A .system as claimed in claim 3, wherein said directing 
means comprises an application engine. 

5. A system as claimed in any preceding claim, wherein said 
entity is a user. 

6. A system as claimed in any preceding claim, wherein said 
entity receives said at least one part of said information in 
response, to a request from entity. 
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7. A system as claimed in any preceding claim, wherein said 
at least one user comprises at least one application. 

8. A system as claimed in any preceding claim, wherein the 
at least one user comprises a presence engine. 

9. A system as claimed in claim 8, wherein said at least one 
application is arrange to register with said presence engine 
said information identifying said application. 

10. A system as claimed in claim 8 or 9, wherein at least one 
of said at least one application and said presence engine is 
arranged to add said identifying information to at least one 
part . 

11. A system as claimed in any preceding claim wherein said 
users comprise user equipment. 

12. A system as claimed in any preceding claim, wherein said 
presence information comprises at least one of the following 
parts of information: Subscriber status; Network status; 
communication means; Contact address, Subscriber provided 
location; Network provided location; text; priority; mood, 
favour i.te colour. 

13 . A system as claimed in any preceding claim, wherein the 
system operates in accordance with a session initiation 
protocol (SIP) . 

14 . A system as claimed in any preceding claim, wherein said 
part of information comprises a tuple. 
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15. A system as claimed in claim 14 , wherein said tuple 
comprises information identifying said user and said 
application identifying information, 

5 16. A system as claimed in any preceding claim, wherein said 
entity is arranged to request only one or more parts of said 
presence information processed by one or more applications of 
said entity. 

10 17. A system as . claimed in claim 16, wherein filtering means 
are provided for providing only the requested parts of said 
presence information. 

18. A system as claimed in claim 17, wherein said filtering 
15 means are provided in at least one of a server; a presence 

server and said at least one user. 

19. A system as claimed in any preceding claim, wherein said 
at least one entity is arranged to use said information to 

20 filter said presence information. 

20. A system as claimed in any preceding claim,- wherein said 
entity application being arranged to process the at least one 
part of the presence information which comprises information 

25 identifying said entity application. 

21. A communication method comprising the steps of: 
providing presence information for an associated user, 

said presence information comprising a plurality of parts, at 
30 least one of said parts comprising information identifying an 
application for which said at least one part is intended; and 

at least one entity obtaining at least one of said parts, 
said at least one entity having at least one entity 



WO 2004/034718 




PCT/IB2002/004381 



application, the at least one entity obtaining the parts 
comprising information identifying said at least one entity 
application, 

5 22. A method as claimed in claim 21 comprising the step of 
processing at said at least one entity application, said at 
least one part of the presence information which comprises 
information identifying said entity application. 

10 23 . A user in a communications system, said user having 
associated presence information, said presence information 
comprising a plurality of parts, said user being arranged to 
provide at least one of said parts with information 
identifying an application for which said at least one part is 

15 intended. 

24. An entity in a communications system, said entity 
comprising: 

at least one application obtaining means for obtaining at 
20 least one part of presence information associated with an 
user, the at least one part comprising information identifying 
an application, the obtaining means being arranged to obtain 
the at least part comprising information identifying said at 
least one application. 

25 

25. A entity as claimed in claim 24, wherein the application 
identified in said at least one part is arranged to process 
said at least one part of the presence information which 
comprises information identifying said application. 
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